HCL Lotus Expeditor wiki: Lotus Expeditor 6.2.3 Integrator Documentation: Installing Expeditor Integrator

Installing Expeditor Integrator

Added by ~Emile Asatoolitader | Edited by ~Andy Froresasonynds on April 5, 2017 | Version 7

Actions ▼

Abstract

Abstract

No abstract provided.

Tags: Integrator

Return to Main Contents

ShowTable of Contents

HideTable of Contents

1 Prerequisites - Application integration back end environment
2 Prerequisites for Remote Server hosting Expeditor integrator
3 Installation of Expeditor integrator
4 Uninstalling Expeditor integrator
- 4.1 Uninstalling the stand alone runtime
- 4.2 Uninstalling the Expeditor integrator operating system service
5 Expeditor integrator file and directory structure

The installation of the IBM Lotus Expeditor integrator affects 3 systems:

the Backbone Service Bus / Application Integration messaging back-end environment (AI),
the central monitoring system (e.g. Tivoli Enterprise Console) and
the server in the remote location (further referred to as remote server; e.g. a store server in the remote supermarkets).

This section describes which prerequisites must be met and how the Expeditor integrator is installed on the remote server (e.g. on a retail store server).

There are different options for the installation of IBM Lotus Expeditor integrator:

a) Manual installation using the provided IBM Lotus Expeditor integrator installer
b) Installation on a reference system of the server at the remote location and packaging the installed image for software distribution using existing IBM (e.g. Tivoli) or third-party tools.

Option a) is for test and development environments, option b) is recommended for mass-deployment in production environments.

Configuration options for Expeditor integrator are discussed in Section 3.

A suggestion for a checklist for the required configuration values is provided in APPENDIX A – Custom Set-up.

Prerequisites - Application integration back end environment

The Expeditor integrator is installed on the remote server (e.g. in the retail supermarket). It needs physical and logical connectivity to the Backbone Service Bus (AI back-end, Message Broker) for message (data) exchange. If remote enterprise monitoring by the Tivoli Enterprise Console is required, the Expeditor integrator will also need to be able to fire TEC Events (e.g. under re-use of the existing Tivoli Endpoint on the remote server).

Many Expeditor integrator configuration settings can be adjusted to the target environment. Please, refer to Section 3 for configuration details.

Connectivity to Application Integration Back end

Back-end connectivity should be checked before the integrator’s back-end connection is tested.

The following check list is an example for an IBM WebSphere MQ based back-end:

Check that the remote server has access through the firewall (use Internet Browser to access the AI back-end Server (Message Broker). By default the used IBM Lotus Expeditor micro broker Bridge of the Expeditor integrator communicates through (the configurable)

MQ Server Port = 1414
with MQ user name and password

The AI Message Broker(s) must be accessible. Check with PING command (recommendation: test with Telnet command as well to test whether the port is accessible).

ping <msgBroker_address>
telnet <msgBroker_address> 1414

Please, check that the AI Message Broker system is available and that the current remote location has an appropriate MQ user account (for reading and writing messages)

MQ User / Password

Note: After successful installation and configuration of Expeditor integrator, the connectivity status information can be retrieved by entering the following commands in the Expeditor integrator console (OSGi console; see chapter 4.3.3 Configuration of Back end Connectivity through Lotus Expeditor micro broker bridge):

checkadapterstatus <adapter_name>
checkmsgserverstatus <pipe_name>

(More Expeditor integrator console commands can be found in section 7 Expeditor Integrator console commands)

Queue Configuration at Application Integration Back end

Figure 2 shows the pre-configured default queues on the micro broker in the Expeditor integrator and the bridged connections to the back-end. For getting started quickly, this queue set-up is recommended on the Messaging Back-end.

The default queue set-up is based on a point-to-point architecture. This can be individually adjusted to customer situations. Publish/Subscribe architectures are also supported.

It is recommended to set-up the back-end messaging system prior the Expeditor integrator installation and configuration to allow for error free operation.

Figure 2: Default Expeditor integrator queue set-up

The suggested default configuration requires the following queues at the messaging back-end:

1 ReqOutQx, 1 ResInQx and 1 CtrlOutQx per location endpoint (remote server) x
1 LogQ and 1 EventQ commonly used by all endpoints

as well as the (Server)DeadletterQ which will contain all those messages that could not be delivered. An IBM MQSeries-typical SyncQ should also be available (see Table 1). This architecture has already proven its feasibility since it is working in production of a large retail company.

Table 1: Back-end message queue default set-up

Back-end Queue	Bridged to local Expeditor integrator queue	Description
ReqOutQx	ReqInQ	-Queues for data messages sent from the back-end to Expeditor integrator (inbound), e.g. messages carrying files -It is recommended to have one ReqOutQ per remote Expeditor integrator runtime (x – stands for an unique ID of the Expeditor integrator runtime, e.g. the LocationId)
ResInQx	ResOutQ	-Queues for data messages sent from back-end to Expeditor integrator (outbound), e.g. messages carrying files -It is recommended to have one ReqOutQ per remote Expeditor integrator runtime (x – stands for an unique ID of the Expeditor integrator runtime, e.g. the LocationId)
CtrlOutQx	CtrlQ	-Queues for control messages sent from the back-end to Expeditor integrator (inbound), e.g. messages carrying Expeditor integrator configuration updates and control commands -It is recommended to have one ReqOutQ per remote Expeditor integrator runtime (x – stands for an unique ID of the Expeditor integrator runtime, e.g. the LocationId)
DeadletterQ	ServerDeadletterQ	-Expeditor integrator places all messages with false message headers or values which are not supported into the local ServerDeadletterQ. These messages will be moved to the DeadletterQ at the back-end so that they are not lost. -Messages with valid headers which can not be processed due to any reason might also be placed into this queue or may even be discarded. This behavior is configurable for the each use-case.
SyncQ		Required system queue for Lotus Expeditor micro broker bridge operation
EventQ	EventQ	-Queue for (business) events created by Expeditor integrator. If configured, filtered (business and application) events can be sent in data messages to the back-end through this queue (see configuration of Custom Event Service). E.g. Transaction Status events -Potential consumes of these events at the back-end would be flows which require status information about triggered defined use cases (e.g. whether the sent price update has been successfully transferred to the 4690 PoS controller; sometimes referred to as Business Monitoring).
LogQ	LogQ	-Queue for (technical) events created by Expeditor integrator. If configured, filtered (technical) Expeditor integrator specific log events can be sent in data messages to the back-end through this queue (see configuration of Custom Log Service). E.g. Application component status events (errors, warnings etc.) - Consumers for these events at the back-end would be systems management services which monitor the status and health of the Expeditor integrator runtimes.

All these queue settings must be also provided in the XPDinteg.xmlfile that contains the Expeditor integrator’s configuration parameter (refer to Section 3 for more details about the integrator configuration).

Connectivity to Tivoli Monitoring

The Expeditor integrator can be enabled to send events using the Tivoli Event Infrastructure Facility (EIF) either directly to the Tivoli Enterprise Console (TEC) or through locally installed Tivoli Endpoints. Please, discuss the following information with the TEC Administrator.

The used TEC event classes are:

XPDINTEG_BUNDLEEVENT
XPDINTEG_LOGEVENT

These classes can be imported as new Rule Base of the TEC EventServer through the provided XPDinteg.baroc configuration file (see <XPDINTEG_HOME>/config/tecserverfile/XPDinteg.baroc).

Check that the remote server hosting the integrator runtime has access through the firewall (ping and telnet), and if required that the Tivoli Endpoint is installed and configured on the remote server (e.g. Store Server).

A list of multiple TEC servers can be accessed. Make sure that the following values are available for each used TEC (These parameters are required for the configuration in the XPDinteg.xml later in this document.):

(Disable or enable sending TEC events to either a local Tivoli endpoint = LCF or directly to the TEC = SOCKET)}}}

(Which logging events should be forwarded: ERROR | WARNING | DEBUG | INFO ?)}}}
com/integrator/XPDintegApplStatusEvent
(Which Expeditor integrator application events should be forwarded?)}}}
com.ibm.rcp.integrator.messagetofilemapper com.ibm.rcp.integrator.transactionfilemapper
(Events from which Expeditor integrator application component should be forwarded?) }}}
INSTALLED
(Which status of the monitored bundle are to be forwarded to the TEC: INSTALLED, STARTED, STOPPED?)}}}

<hostname>=IP address or IP hostname of the TEC server
<port>=5529 (port of the TEC server; default = 5529)
<maintenance-mode>= ON | OFF (Should events be forwarded during local Maintenance Mode?)
=DISABLE | SOCKET | LCF
<event-max-size>=4 (max size of the forwarded events in kB)
<space-replacement>=true (Switch space replacement in events on or off: true | false)
ERROR

If concreteStart events should not be sent to TEC, use an empty topics element in the XPDinteg.xml file:

If bundle events should not be sent to TEC, use an empty monitored-bundles element as well as an empty monitored-status element in the XPDinteg.xml file:

<monitored-bundles></monitored-bundles>

<monitored-status></monitored-status>

(See chapter iTMS Configuration Options (Section_13) for more details.)

Please, make sure that the following DLLs are available if a locally installed Tivoli Endpoint is used on the remote server for sending events to the Tivoli Enterprise Console (TEC):

libteceif.dll
libtecgw.dll
teclcf.dll

These DLLs can be downloaded from the IBM Support Site with the Tivoli Endpoint Fixpack and can be simply copied to the remote server where the Expeditor integrator is located (see Tivoli Endpoint Installation and Configuration Example in APPENDIX B – Technical Details).

The following steps explain how the provided XPDINTEG event classes can be enabled in the Tivoli Enterprise Console (TEC) v4.1:

1. Make sure the Tivoli Services are running, e.g. Tivoli Object Dispatcher and Tivoli Remote Execution Service

2. Start Tivoli Desktop and make sure that the EventServer is running (Click on EventServer with right mouse button and choose Start-up.)

3. Bring up the Rule Bases (Click on EventServer with right mouse button and choose Rule Bases…)

4. Create a new Rule Base: Create | Rule Base. Provide a name and select a directory where the rule configuration is saved, e.g.

Name = XPDinteg
Directory = backbone-service-bus:C:/Development/tec_rules

5. After creating the Rule Base, import the XPDinteg.baroc file into the XPDinteg Rule Base (The XPDinteg.baroc baroc file is provided with each XPDinteg runtime under <XPDINTEG_HOME>/config/tecserverfile)

6. Right click on the created new Rule Base (e.g. XPDinteg Rule Base), go to Class Definitions area and check the Import Class Definitions check box. In the Directory Path area, click on File and select the baroc file, e.g.

Directory Path = backbone-service-bus:C:/user/XPDinteg.baroc

7. Make sure that Insert After is selected in the Position to insert imported class file area. Click Import & Close.

8. Compile the XPDinteg Rule Base: Right click on the XPDinteg Rule Bases and select Compile…

9. Load the XPDinteg Rule Base: Right click and select Load… Select Load and activate the rule base.

10. Quit the Tivoli Enterprise Console and Tivoli Desktop (Depending to the operating system, the services may need to be re-started to activate the new classes.)

Tivoli Endpoint Installation and Configuration Example in APPENDIX B – Technical Details.

Important: The Windows PATH variable must also point to these DLLs.

The default ports for the Endpoint communication are

Endpoint Gateway communication default port (Server): 9494
Local Endpoint communication default port (Client): 9495

These ports can be adjusted to the local environment in the <TIVOLI_HOME>\lcf\dat\1\last.cfg (lcfd_port and lcfd_preferred_port; <TIVOLI_HOME> is the installation path of the Tivoli Endpoint, e.g. C:\Program Files\Tivoli).

The configuration of the Expeditor integrator Tivoli Monitoring Service (ITMS) for sending application events to the TEC requires some more configuration steps. The TecLcfUtil utility supports the Administrator during these configuration steps.

Please, refer to chapter iTMS Configuration Options (Section_13) for the description of the provided TecLcfUtil utility and to APPENDIX B – Technical Details for more information about the Tivoli Endpoint installation and configuration.

Optional: Connectivity to Back end Management Server

This section is optional.

There are different options for the remote Expeditor integrator runtime being centrally managed:

1. Management through IBM Lotus Expeditor Server
The Expeditor Server offers remote management of the IBM Lotus Expeditor Clients through the standardized Eclipse RCP Installation Manager. The Eclipse RCP management allows for management of the Expeditor Client runtime and the Expeditor integrator RCP plug-ins. This includes installation, update, start and stop operations.
2. Management through IBM WebSphere Premises Server
Since the Expeditor integrator uses the standard OSGi Configuration Admin Service interface to maintain its configuration similar to the IBM WebSphere Data Capture devices, the Expeditor integrator runtime’s configuration can also be managed by the Premises Server (Configuration Management).
3. Management using Expeditor integrator control facilities
Expeditor integrator provides control queues through which defined control messages can be received to kick off local control actions. For example, configuration changes can be applied, the Maintenance Mode can be toggled on / off and a House Keeping Flow can be triggered.

Please, refer to your remote management architecture and determine which server-managed approach is taken. Depending on the chosen option, double check whether there is a server connection available from your Expeditor integrator runtime.

Note: Make sure that the Back-end Management Server can be accessed through the configured port (firewall settings!).

Prerequisites for Remote Server hosting Expeditor integrator

The Expeditor integrator is installed on a server in the remote location (e.g. a store server in the hypermarkets). The remote server hosting the integrator runtime must provide the following pre-requisites.

Prerequisites for the Expeditor integrator

The Expeditor integrator is based on the OSGi® Framework (provided with Eclipse® RCP; Equinox). The OSGi Framework is a Java Service Platform that runs as a Java executable.

The Expeditor integrator product is provided as zipped installation image that contains its own directory structure. This file needs to be unzipped in an installation directory (further referred to as <XPDINTEG_INSTALL>). After running the installation routine, the Expeditor integrator runtime is installed in the directory which was chosen during the installation procedure (referred to as Expeditor integrator home directory: <XPDINTEG_HOME>).

Please, make sure that the user account of the operating system under which the Expeditor integrator is running has appropriate (read/write) access rights to this directory.

Table 2: Expeditor integrator runtime prerequisites

Prerequisite	Value (save your values here)	Comment
LocationId		Unique ID for the remote location/server (e.g. a store ID); this value is also set in the JMS Message headers
Domain name of the remote server		Full-qualified domain name
IP Address of the remote server
User account under which the Expeditor integrator is running
User account under which the Expeditor integrator is registered as Windows Service	Recommendation: system account (that is allowed to log to console)	The registered Windows Service needs to be started with this user account.
Directory for the Expeditor integrator		is the *<XPDINTEG_HOME>* variable
<XPDINTEG_HOME> contains enough disk space	- for Runtime: 800 MB	250 MB for pure Runtime plus 550 MB for temporary storage of messages in the File System and transaction logs.

The above provided parameters will also be used during the Expeditor integrator installation (see chapter ‎Installation of Expeditor integrator).

Configuration of remote FTP or SSH Server

IBM Lotus Expeditor integrator supports file transfer between the integrator runtime and connected file servers, which can be accessed through FTP and SSH.

For example, in retail environments, the Expeditor integrator can transfer files between the remote server and the 4690 PoS Controller (4690EL). The 4690 PoS Controller is a closed system that can only be accessed by using the built-in FTP Server.

If a file server is accessed using FTP/SSH, please, make sure that all access information is available (see Table 3).

Table 3: FTP Server information

Parameter	Value (save your values here)	Comment
4690EL and/or FTP/SSH server name		as fully-qualified domain name
4690EL and/or FTP/SSH server IP address
FTP/SSH User / Password		This user needs read and write access to the appropriate directories
FTP Timeout value		Should be set pretty high so that connection losses between the Expeditor integrator and the remote file server are minimized
List of FTP/SSH directories for READ access		This directories will be read by the Expeditor integrator
List of FTP/SSH directories for WRITE access		Expeditor integrator needs write access

This information is also required for all other file servers (FTP/SSH, 4690EL Controllers in the store) that need to be accessed by the Expeditor integrator.

Configuration of Local File System

The Local File System is the file system of the computer on which the Expeditor integrator is installed (referred to as remote server). In retail environments, this would be the store server in the hypermarket. The following settings must be considered to allow the Expeditor integrator to access the local file system.

Table 4: Local File System access information

Parameter	Value (save your values here)	Comment
User account: File system access rights for the account under which the Expeditor integrator is running		Make sure that the Expeditor integrator user account has read and write access to the target and source directories for the file transfer
List of directories that need READ access		Directories that are read by the Expeditor integrator
List of directories that need WRITE access		Directories that are written by the Expeditor integrator

Installation of Expeditor integrator

IBM Lotus Expeditor integrator product is delivered as installation package with its own installer. Please, unzip the installation package to a temporary directory of your choice (<XPDINTEG_INSTALLDIR> or <XPDINTEG_HOME>). The Expeditor integrator runtime is installed by running the provided installer.

Another option for mass rollout scenarios would be to install the Expeditor integrator on a reference system. Since the Expeditor integrator is provided with its own self-contained runtime environment, the created installation image in the Expeditor integrator home directory (<XPDINTEG_HOME>) could be re-packaged (zipped) and moved/copied to any other directory and computer.

Installation using the provided installer

Installing Expeditor integrator under Windows

For Windows environments run:

<XPDINTEG_INSTALLDIR>\desktop\install\setup.exe

During the installation procedure, provide the directory to which the Expeditor runtime should be deployed. This directory is further referred to as Expeditor integrator home directory (<XPDINTEG_HOME>).

Note: If an IBM Lotus Expeditor runtime is already installed on the server, the installer kicks off the uninstaller first to remove any existing old runtime. Also note, that Windows Registry entries are created by the Windows installer (e.g. for uninstall information) and that registry entries are created for the Expeditor integrator Windows Service if the “Run as a service…” option was selected during installation or the Windows service was installed afterwards (see chapter ‎2.4.2 Uninstalling the Expeditor integrator operating system service).

Installing Expeditor integrator under Linux

The Expeditor integrator installation image for Linux is delivered as RPM and DEB package.
By default, the Expeditor integrator workspace directory is created in the home directory of the Linux user account with which the installation is executed (e.g. /home/myuser/Lotus/XPD). If the workspace directory should be contained with the Expeditor integrator installation directory, the following lines should be added to /etc/ibm/integrator/install.options(/etc/ibm/integrator must be created if it does not exist.):

LICENSEACCEPTED='true'
RCPDATA='/opt/ibm/lotus/Integrator/workspace'

RCPDATA holds the link to the directory under which the Expeditor integrator workspace will be located. In addition, the workspace directory location can be changed after installation by editing the rcp.data property in the <XPDINTEG_HOME>/rcp/rcplauncher.properties file, e.g. change it to:

rcp.data=${rcp.home}/workspace

Note: If Expeditor integrator is used on a system without graphic support as well as on 64 bit Linux systems, the following line needs to be added to the install.options file:

PROV_VMARGS='-DXPD.noLinuxUI=TRUE'

After successful installation, the following files must be edited:

· <XPDINTEG_HOME>/XPDintegStart.sh
· <XPDINTEG_HOME>/XPDintegUpdate.sh
· <XPDINTEG_HOME>/services/XPDintegStartHelper.sh

Add this parameter to the rcplauncher calls After the installation, double check that <XPDINTEG_HOME>/rcp/rcplauncher.properties contains these two lines:

…/rcp/rcplauncher … -DXPD.noLinuxUI=TRUE

Also, make sure the libstdc++.so.6 library is installed (e.g. under /usr/lib or /usr/lib64).

Follow these steps for installation :

Copy the Expeditor integrator install image to a temporary directory (e.g. /tmp/install).
Open a console window and switch to a local user account which has installation rights (read/write/execute permissions on /opt directory), e.g. to the root account.
Use the RPM / console tool for running the installation, e.g. by entering this in the console:
RPM package: rpm –i integrator-<version>-<build>.i586.rpm
DEB package: gdebi integrator-<version>-<build>.i586.rpm
(or by double clicking on the RPM/DEB install image in your file browser window)
This copies all Expeditor integrator files to /opt/ibm/lotus/Integrator by default (=<XPDINTEG_HOME>).

Note:

Make sure the Expeditor integrator target directories ..
<XPDINTEG_HOME> (= installation directory; default: /opt/ibm/lotus/Integrator),
.workspace (= RCP workspace directory; set in RCPDATA variable above),
/temp

… have correct access rights for the user/process under which Expeditor integrator is installed and started (read/write access to all sub directories of (<XPDINTEG_HOME>) and execute right for XPDinteg*.sh script files.).

The Expeditor integrator installation procedure copies the file structure from the setup (rpm or deb package) to the selected installation directory (default=/opt/ibm/lotus/Integrator). The executable files in the target folder are created with 755 permissions. When Expeditor integrator is launched for the first time after installation, LAP (License Acceptance Protocol) is invoked. This creates temporary files with _lap* as name prefix in the /tmp directory. These files have the following permissions and are removed once LAP has successfully completed:

_lap*err 644
_lap*result 644
_lap*out 644
_lap*invoker 755
_lap*wrapper 755

Expeditor integrator can also be started as Service (Daemon) under the supported Linux distributions. If this start-up option is preferred, the install.options file should contain information about the Linux Daemon configuration PRIOR the installation (see chapter 2.3.4 Installing Expeditor integrator to run as Linux Service).
When installing Expeditor integrator on up-to-date 64bit linux systems, warnings might occur when running the restart script. Even though the restart and reset itself works properly, warning messages are displayed in the OSGi console. In order to suppress these warnings, please add the following lline to the file(<XPDINTEG_HOME>)/rcp/plugins/com.ibm.rcp.base_/rcpinstall.properties:

-DXPD.noLinuxUI=TRUE'

Installing Expeditor integrator from a created reference image

Follow the installation steps provided above to create the Expeditor integrator runtime in its home directory (<XPDINTEG_HOME>). Package this home directory (e.g. as XPDinteg_v62x.zip ZIP file) and provide it as installation image for further distribution in your enterprise. You might want to do some basic configuration before re-packaging Expeditor integrator runtime. Please, refer to section 3 for available configuration options.

Installation of the custom distribution package:
The custom distribution package (e.g. XPDinteg_v62x.zip) can be extracted in any folder of the target system (remote server; store server). It only must be assured that the user account that runs the application has appropriate Read and Write access rights to the installation folder (<XPDINTEG_HOME> folder).

The following steps are required for the installation:

Copy the provided ZIP to the target location (<XPDINTEG_HOME> = installation folder of the Expeditor integrator)
Extract the ZIP file within this folder

After Expeditor integrator installation

The Expeditor integrator must be configured according to the location endpoint’s (e.g. retail store’s) and back-end system’s environment settings. Configure the Expeditor integrator manually or through one of the available remote management server options. Please, refer to section 3. for details.
A custom distribution package might already contain a base configuration. Please, refer to your Administrator whether additional manual installation steps are required.
After configuration, ensure that your local computer has connectivity to all required external systems (e.g. the file server, the messaging back-end, the monitoring back-end).
Start the Expeditor integrator in a console window (Console Mode):
Start the Expeditor integrator by executing the XPDintegStart.bat on Windows and XPDintegStart.sh on Linux operating systems. This will start up the Expeditor integrator. By default a console output window is shown.

Note: When Expeditor integrator is started the first time or started after Reset, you may be prompted for accepting the license agreement (being displayed in additional console window). when LICENSACCEPTED=’TRUE’ was not set in the install.options file before installation.). After platform Reset license management related files (_lapXXXinvoker/wrapper etc.) are created in the /temp (/tmp) directory. This temporary directory location can also be configured by adding this parameter:

=-Djava.io.tmpdir=mytmpdirectory

to the (<XPDINTEG_HOME>)/rcp/eclipse/plugins/com.ibm.rcp.j2se.

/jvm.propertiesfile.
Also, the console window may not be displayed. In this case, stop the expeditor process (e.g. use pidof expeditor to retrieve the process number and enter kill <process_no>.) and restart the runtime with XPDintegStart.sh

Start the Expeditor integrator as operating system Service or Daemon:
For Windows, please, refer to chapter ‎Installing Expeditor integrator to run as Windows Service
For Linux, please, refer to chapter Installing Expeditor integrator to run as a Linux Service
For convenience, the Expeditor integrator GUI (http://localhost:8777/ui) should be used for further configuration and management steps (see section 7)
For Start/Stop/Reset of Expeditor integrator, please refer to chapter 5.1 Starting, Stopping, Resetting Expeditor integrator .

All start/stop/reset commands can be triggered remotely through specific Expeditor integrator control messages (‎Ref_2.).

Installing Expeditor integrator to run as Windows Service

The IBM Lotus Expeditor integrator can also be installed as Windows operating system Service. In this case, the integrator runtime can be started and stopped automatically or through remote Windows Services management tools.
Note: Windows service for Windows 2008 is only working under the Administrator account in non-console mode (no OSGi console is displayed)!

Follow these steps to enable starting Expeditor integrator as service:

where:

install installs the Windows Service
manual or auto indicate the service type (accepted parameters are auto for starting this Windows Service automatically or manual for manual start-up)
Check that the IBM Lotus Expeditor integrator Service Package was installed. The package installation added the XPDintegSvc.exe file to <XPDINTEG_HOME>/services directory.
Install the Expeditor integrator service by running
XPDintegSvc.exe install manual
Optional parameters:

2.3.4.1 Install Expeditor integrator as Interactive Windows Service

-console starts Expeditor integrator as Interactive Service with in console window (OSGi Console)
-reset resets the Expeditor integrator (Use with care, because this deletes log files, OSGi config store and Lotus Expeditor micro broker queues and their content! See chapter 5.1 Starting, Stopping, Resetting Expeditor integrator )

Recommendation for the service installation:

XPDintegSvc.exe install manual -console

This will create the Windows Service for Expeditor integrator. The service must be started manually and displays the Expeditor integrator OSGi Console window.

The Expeditor integrator Windows Service is installed under the service name IBM Lotus Expeditor integrator and service description IBM Lotus Expeditor integrator service.

Figure 3: Windows Service Panel

Double check in the Windows Service Panel that the Expeditor integrator service was installed (see Figure 3)
You may also want to set the service to be started automatically during system start and open the Expeditor integrator console window. In this case, double click the Expeditor integrator service in the Windows Services Panel and make sure that the created service is set to:

General tab: Startup type = Automatic
Log on tab: Log on as Local System account and Allow service to interact with desktop(Installation as Interactive Service is required for interaction with the desktop. See chapter 2.3.4.1 Install Expeditor integrator as Interactive Windows Service).

Test the installation by starting the service.

Note: If the Windows Service is installed, the Expeditor integrator runtime can not be moved out of its home directory anymore. Otherwise the Windows Service will not work. For un-installation, please refer to chapter ‎2.4 Uninstalling Expeditor integrator.

The XPDintegSvc.exe provides additional commands for controlling the installed service:

start starts the service
restart restarts the service
stop stops the service
uninstall un-installs the service

For example,

XPDintegSvc.exe start -console

triggers the installed Windows Service which starts the Expeditor integrator runtime in an OSGi Console window when installed as Interactive Service, see chapter 2.3.4.1 Install Expeditor integrator as Interactive Windows Service).

Install Expeditor integrator as Interactive Windows Service

Installing the Windows service with the option “-console” (e.g. XPDintegSvc install manual -console) creates an according interactive Windows service which is required to display the console:

· Double check in the Windows Service Management Console that the Expeditor integrator service was installed (see Figure 3)

· You may also want to set the service to be started automatically during system start. In this case, double click the Expeditor integrator service in the Windows Services panel and make sure that the created service is set to:

General tab: Startup type = Automatic
Log on tab: Log on as Local System account and Allow service to interact with desktop

· Test the installation by starting the service.

Important: You must install the Expeditor integrator Windows Service with the manual option to force installing as interactive service! After successful installation, you can change the service to Automatic start in the Windows Service Management Console.

Because interactive services receive a request to close all windows when the user logs out (“CTRL_LOGGOFF_EVENT”), the Expeditor integrator runtime is stopped in this case. The following line of the file /rcp/deploy/jvm.properties needs to be activated (by removing the “#”) in order to avoid this:

vmarg.Xrs=-Xrs

If you start the Windows service after this change, the OSGi console is displayed and the service is not stopped when the user logs out.

Accessing the OSGi console on Windows Server 2008

When installing IBM Lotus Expeditor integrator as Windows service under Windows Server 2008, the OSGi Console won’t be displayed after the service is started.

This is related to the Session 0 isolation of Windows services that use desktop interaction and causes the OSGi Console to be started in UI Session_0 while the logged in user is connected to session > 0.

In order to access the OSGi Console, the Interactive Service Detection Service needs to be enabled which detects services that connect to Session 0.

· Enable the Interactive Service Detection Service by running the following command as Administrator:

sc config ui0detect start= auto

· Start the Interactive Service Detection Service by running the following command as Administrator:

sc start ui0detect

Once the Interactive Service Detection Service is enabled and started, a popup window (Interactive service dialog detection) will be displayed after starting the IBM Lotus Expeditor Integrator service. Select “Show me the message” to switch to Session 0 were the OSGi Console is displayed.

When enabled, the hidden OSGi console can also be accessed through telnet (see chapter 5.12.7 Remote access to OSGi console when running as service)

Installing Expeditor integrator to run as a Linux Service (Daemon)

The IBM Lotus Expeditor integrator can also be installed as service (daemon) under the supported Linux distributions. In this case, the integrator runtime can be started as operating system daemon during system start-up.
The installation of the Daemon option must be configured in the /etc/ibm/integrator/install.options file before the installation procedure is kicked of. The following options can be added to the installa.options file:

Table 5: Parameter options for Linux Daemon installation

Parameter	Supported Values	Description
ENABLEDAEMON	Set to 'true' if daemon support needs to be enabled.	If not specified or 'false' daemon support is not enabled. Required to enable daemon support.
DAEMONAUTOSTART	Set to 'true' if daemon support should be autostarted	If not specified or 'false' daemon support needs to be manually started. Required to ensure that daemon is autostarted. If 'true', Symbolic links are created.
INTGUSER	Set to specified user name if Integrator is to be run by a specific user account	If not specified then all integrator files/folders will be owned by root. Required to ensure that integrator files/folders are owned by a specific user.
INTGGROUP	Set to specified group if you want users from a specific group to own Integrator files/folders.	If not specified then group owner for all integrator files/folders will be root. Required to ensure that a specific group owns integrator files/folders.

Example content for install.options file:

ENABLEDAEMON='true'

DAEMONAUTOSTART='true'

ENABLEDAEMON='true'

DAEMONAUTOSTART='true'

INTGUSER='xpdadmin'

INTGGROUP='intg'

INTGUSER='xpdadmin'

INTGGROUP='intg

If Expeditr integrator Linux daemon support is to be enabled and daemon should be autostarted on platform startup:
If Expeditor integrator Linux daemon support is to be enabled and daemon should not be autostarted on platform startup:
If Expeditor integrator Linux daemon support is to be enabled, daemon should be autostarted on platform startup and Integrator files should be owned by specific user and group:
Note: It is recommended you create a separate group for Expeditor integrator. If integrator Linux daemon support is not required but integrator files should be owned by specific user and group:
When using the Linux daemon, it is also recommended to avoid the license acceptance prompt after each reset by adding this line to the install.options file:
LICENSEACCEPTED='true'

Use the following command for controlling the service:

/etc/init.d/xpdinteg <command> <option>

<command> options:

start
stop
restart

possible <option>:

-console starts Expeditor integrator in console window (OSGi Console)
-reset resets the Expeditor integrator (Use with care, because this deletes log files, OSGi config store and Lotus Expeditor micro broker queues and their content! See chapter 5.1 Starting, Stopping, Resetting Expeditor integrator )

e.g. starting the Expeditor integrator service in a console window:

```
/etc/init.d/xpdinteg start -console 
```

Please, also consider information in chapter 2.3.6 General considerations when installed as operating system service.

General considerations when installed as operating system service

IBM Lotus Expeditor integrator can be installed as operating system service or daemon using a given system user account. The installation routines are operating system specific so that support is only guaranteed for supported operating systems (OS). Support for tolerated OS is only given when problems can be re-produced on supported OS.

Important: Expeditor integrator runtime creates user specific security information for the user account under which it is started during first startup after installation and platform RESET. If Expeditor integrator runtime is started by another operating system user later, it will fail with security validation exceptions . This is the case for example, when integrator is started with the XPDintegStart.bat/sh script, although it was initially installed and operated as operating system service (using a different user account).

Uninstalling Expeditor integrator

Uninstalling the stand alone runtime

Windows:
The Expeditor integrator can be simply un-installed by running the provided installer again, run the <XPDINTEG_HOME>/uninstall.bat or by using the operating system software un-install feature
For Windows environments follow these steps:

Stop all Expeditor client and Expeditor integrator runtimes.
Go to Windows Control Panel (Start | Windows Control Panel) and select Add or Remove Programs
Locate the IBM Lotus Expeditor Client entry and click on Remove

Linux:
Use the package manager of your Linux distribution to remove the Expeditor integrator installation image (RPM for RedHat and SuSE; DPKG for Ubuntu system).

Follow these steps if rpm Linux console commands are used:

Search for your installed Expeditor integrator runtime (e.g. package_name), e.g.
rpm -q -a | grep integrator
Run the un-installation command with the located Expeditor integrator installation package:
rpm -e package_name

For Debian Linux package (dpkg):

Get the installed package name (e.g. package_name):
dpkg -l | grep integrator
Un-install the Expeditor integrator package:
dpkg -r package_name

Please, double check the Expeditor integrator home directory is removed (costum changes might still be in there). Also, make sure that the Expeditor integrator operating system service is removed in case it was installed (refer to chapter 2.4.2 Uninstalling the Expeditor integrator operating system service for manual removal of the service).

Uninstalling the Expeditor integrator operating system service

If the Expeditor integrator service was not removed by the un-installer, you can also delete it manually.
Follow these steps for Windows:

Go to <XPDINTEG_HOME>/services and run
```
XPDintegSvc.exe uninstall 
```

Under Linux, the service is automatically removed when the package manager is used for un-installation.

Expeditor integrator file and directory structure

The Expeditor integrator product is provided as installation image. After the running the installer, the Expeditor integrator instance is located in the directory which was selected during the installation process (home directory <XPDINTEG_HOME>).

After installation, this home directory contains its own folder structure.

Table 6: Expeditor integrator folder structure

Folder / Files	Description
config / XPDinteg.xml	basic configuration file for Expeditor integrator
config / XPDintegRoles.xml	optionally displayed file which includes currently used user names and roles for accessing Expeditor integrator (e.g for the REST Adapter and the GUI)
config / backup	Folder which contains backup copies of older versions of the XPDinteg.xml for revision (created by the House Keeping flow).
config / new	Folder where the XPDinteg.xml needs to be copied for configuration update initiation after manual updates of this file.
config / system	folder with the system configuration. The included files must not be changed. XPDinteg.xsl/xsd contain the schema for the XPDinteg.xml XPDintegConfig.xml contains the internal structure of the Config Admin configuration of the Expeditor integrator. XPDintegDefaultRoles.xml holds required default user names and roles for accessing Expeditor integrator. micro-acl.xml provides the micro broker access control list configuration for messaging clients. XPDintegMBUsers.xml contains micro broker (messaging) client users which can be considered in the micro broker ACL (micro-acl.xml). micro-acl_for_LocalMaint.xml and XPDintegMBUsers_for_LocalMaint.xml contain specific configuration settings that are used to run Local Maintenance Flow
config / maint	Folder contains control information for the Local Maintenance Flow, e.g. files StartLocalMaintenance.txt and StartLocalMaintenance.done
config / system / ssl	Folder can contain certificates which are required for accessing the local Webcontainer
config / tecserverfile / XPDinteg.baroc	file for configuration purposes of the Event Server of TEC (needs to be imported there)
datatrans datatrans / inbound datatrans / outbound	folder for default file transfer (inbound and outbound) inbound/readme.txt provides instructions for inbound file transfer samples outbound/sample.txt file in outbound folder is transferred to messaging back-end if sample flows and adapters are configured.
eclipse	folder with IBM and Expeditor integrator components and executables
flowdefs	folder with Expeditor integrator flow definition files (for Expeditor integrator Application Control Service, ACS). Each file contains a defined use case implementation.
flowdefs/system	subfolder which contains all Expeditor integrator system and management flows (e.g. for configuration update). Included files must not be changed).
flowdefs/default	subfolder which contains Expeditor integrator default flows for file transmission (FTP, local file system and SSH flows), database and message to message interaction. Flow definitions should only be changed if required (not recommended).
ITML / EXP_DC0602.SYS2	required by Expeditor Server Client Management for runtime identification and management (IBM software group requirement)
license	folder contains license files in different languages
persistent	folder with Lotus Expeditor micro broker log and data files, transaction log/trace files and other persistently stored files
rcp rcp / startcollector.bat/sh	folder with core Equinox executables and platform files (Eclipse) StartCollector.ba/sht is the batch file required for the IBM Support Assistant (ISA)
samples	Folder contains examples for Expeditor integrator configuration, ACS flow definitions, messages, ACS Activities, and Resource Adapter implementations (samples/config, samples/flowdefs, samples/messages, samples/activities, samples/resourceadapters)
services services / XPDintegSvc.exe	Executables and helper files for installing, un-installing, starting and stopping Expeditor integrator as a Windows Service: (also included for Linux and Windows: XPDintegSvc.jar/properties, XPDintegRestart.bat/sh, and for Windows only: XPDintegSvc.bat, XPDintegSvcStatus.bat, XPDintegMgr.exe) Note: XPDintegRestart.bat/sh is used by the runtime and should not be executed manually
workspace / logs / StartUpProblems.log	Contains log entries in case of Expeditor integrator start-up problems. Located in the workspace/logs folder.
tools	Folder that contains additional tools: -the Expeditor integrator password utility (PasswordUtil) -the Expeditor integrator (TecLcfUtil) -the Expeditor integrator configuration transformation tool (ConfigTransformerTool) -IBM micro broker trace tool (MBtrace)
tools/tec	Folder contains the required Tivoli Endpoint DLLs from FP05 (libteceif.dll, libtecgw.dll, teclcf.dll)
workspace	Eclipse workspace directory that is created after the application was started the first time
workspace/logs	standard Eclipse RCP logging directory
version.dat	File that contains the version and build information of the current Expeditor integrator
resetscript/XPDintegReset.bat/sh	Batch file that sets Expeditor integrator environment settings after the application was installed on the Store Server (run only once!)
XPDintegStart.bat/sh	Executable that starts the Expeditor integrator manually (if not started as Service). *Note:* It is not possible to start Expeditor integrator manually and operate it as service at the same time!
XPDintegMaint.bat	Windows only: Script tool for local maintenance support. This includes backing up and deleting log files and turning MQJMS trace on/off.
XPDintegUpdate.sh	Linux only: Script which is required for updating Expeditor integrator runtime under Linux (Provisioning API call).

The <XPDINTEG_INSTALLDIR>/doc folder contains the Administrators and the Using the IBM Expeditor integrator platform which include details about the installation, configuration, operation and use of the Lotus Expeditor integrator. It is recommended to copy this folder into the <XPDINTEG_HOME> directory after installation.

The version.dat file contains Expeditor integrator build information that should be provided to the IBM Support in case of questions.

The Expeditor integrator home directory also contains a tools folder if the integrator-tools feature was installed. This folder contains tools that are helpful for the development, operation and test of the Expeditor integrator. Currently, the tools listed in Table 7 are included.

Table 7: Content of "tools" folder

Folder / File	Start tool with	Comment
PasswordUtil (in XPDintegTool.zip)	PasswordUtil.bat or PasswordUtil.sh	Expeditor integrator Password utility that helps to encrypt credentials (e.g. FTP Server password) that must be stored in the XPDinteg.xml file
TecLcfUtil.zip (in XPDintegTool.zip)	TecLcfUtil.bat or TecLcfUtil.sh	Tool for the configuration and set-up of the Tivoli Endpoint environment settings on the remote server.
XPDintegConfigTransformer tool (in XPDintegTool.zip)	XPDintegConfigTransformer.bat or XPDintegConfigTransformer.sh	Tool which creates the internally used configuration structure (XDPintegConfig.xml) out of the XPDinteg.xml. This can be used for a quick validation of the XPDinteg.xml.
MBtrace tool (in XPDintegTool.zip)	MBtrace.bat	Tool to create micro broker trace files
Optional:
tools/tec	-	Folder contains the required Tivoli Endpoint DLLs from FP05 (libteceif.dll, libtecgw.dll, teclcf.dll). These DLLs can be copied onto the Store Serer if the Tivoli Endpoint is used for sending TEC events. The Windows PATH variable needs an entry for these DLLs. A lcf_env.cmd file sample is also included (*lcf_env.cmd.sample*)
CustomDeploymentTool.zip		Tool which supports custom deployment. The tool resides on a ConfigQOut and ConfigQIn at the messaging back-end and interacts with the remote Expeditor integrator runtimes for initial configuration (bootstrapping). Not included in build.

Make sure that the PasswordUtil.xxx file contains the relative path to a Java JRE (by default is set to the runtime environment provided with the Expeditor integrator).